Such mobile services as for example browsing, multimedia messaging, mobile e-mail and calendar synchronization can only be used if a mobile phone is configured correctly. The configuration can be done manually by a user, or automatically by downloading the configuration settings. The process of managing device settings and applications is called device management. When receiving the settings the user saves them into the device after which the user is able to use the service.
The device management can be implemented by means of two types of messages. The first message used is aimed for bootstrapping a device management session and the following messages used are for initiating the session. The purpose of the bootstrap message is to change a state for a device. This means that the device is moved from an “unprovisioned” empty state to a “provisioned” state where it can initiate a device management session. The bootstrap process shares a set of configuration information between the device and the network. This configuration information comprises information e.g. about a network access point and a proxy.
There are currently two ways to perform the bootstrapping, customized and server-initiated bootstrap. In customized bootstrap, devices are loaded with device management bootstrap information at manufacture, and in server-initiated bootstrap a device management server sends bootstrap information via a known push mechanism, e.g. WAP Push or OBEX (OBject EXchange). The bootstrap message is transferred to the client device by the server to configure the client for the basic DM/CP (Device Management/Client Provisioning) server settings. The PROVURL parameter (including host and path) of the bootstrap message defines a location of the server. PROVURL should be unique within the device, and does thus identify a separate configuration context. The bootstrapping process needs to be performed only the first time when the DM server needs to establish communication with the DM client. After bootstrapping the bootstrapped parameter is set to “No” in the device, whereby the device cannot be bootstrapped again.
After bootstrapping, the other message, notification message, is used. When the client is bootstrapped, the following sessions are configured by means of a notification message. The DM server informs—by means of the notification message—the DM client to connect and establish the device management session. The notification operation needs to be done each time the server wants the client to establish a management session.
Therefore, when the DM server sends communication to DM client for the first time, the steps are as follows:                1. Bootstrap message from server to client        2. Notification message from server to client        3. DM session information, credentials, device information from client to server        
Sequence step 2 is optional, if initiation parameters are added to the bootstrap message. This means that for the first time the DM server can send an initiation parameter embedded in the bootstrap message, which tells the client to initiate a DM session after the bootstrapping part is done.
When the DM server sends communication to DM client for the following times after bootstrapping, the steps are as follows:                1. Notification message from server to client        2. DM session information, credentials and device information from client to server        
It can be seen that the whole device management process proceeds via at least two steps, wherein the first steps is for bootstrapping and the second is for initiation.
When e.g. communication configuration is downloaded through a telecommunication network the server usually is aware of whether the device has been bootstrapped or whether the bootstrapping needs to be done. This is possible during one-way communication.
Currently mobile terminals are capable of two-way communication (browsing), where less information is transferred to the corresponding server than in one-way communication. Due to two-way communication the server is not always aware of which terminal is at the other end, and how it is configured. It is also possible that the terminal in question has updated its Firmware, whereby any configuration therein may be lost. Therefore, even if the server identified the terminal in question, it would not know what is the current state of that terminal.
Therefore the server is not able to select which of the two messages is needed at that time. As a result, the server may send a notification message even though a bootstrap message is needed, whereby the DM session fails.
Currently there seems not to be any solution for easing the overall process for the server but also for the client terminal. With existing methods correct information is possible to send, if the server can identify the terminal and identify its configuration. However, that is only possible, if the terminal sends—every time a communication is begun—information about its setting. This, naturally, increases the data transfer between the client and the terminal. For improving user experience when using mobile services and facilitating the device management, all inconvenient tasks should be minimized for the user. As an inconvenient task one can think of the failed device management session, roundtrip messages between client and server and difficult configuration process for the user.